Переход в производство: мышление о развертывании

Этот заключительный модуль соединяет разрыв между успешными исследованиями — где мы достигли высокой точности в ноутбуке — и надежной реализацией. Развертывание — это критический процесс преобразования модели PyTorch в минимальную, самодостаточную службу способную эффективно предоставлять прогнозы конечным пользователям с низкой задержкой и высокой доступностью.

1. Смена мышления при производстве

Экспериментальная среда Jupyter-ноутбука является состоятельной и хрупкой для использования в производственной среде. Нам необходимо переписать наш код из экспериментального скрипта в структурированные, модульные компоненты, подходящие для одновременных запросов, оптимизации ресурсов и бесшовной интеграции в более крупные системы.

Низкая задержка вывода: Достижение времени предсказания, постоянно ниже целевых порогов (например, $50\text{мс}$), что критически важно для приложений в реальном времени.

Высокая доступность: Проектирование службы так, чтобы она была надежной, несостоятельной и способной быстро восстанавливаться после сбоя.

Воспроизводимость: Обеспечение того, чтобы развернутая модель и среда (зависимости, веса, конфигурация) точно соответствовали подтвержденным результатам исследований.

Фокус: сервис модели

Вместо развертывания всего скрипта обучения мы развертываем минимальную, самодостаточную обертку службы. Эта служба должна выполнять только три задачи: загрузить оптимизированный артефакт модели, применить предварительную обработку входных данных и выполнить прямой проход для возврата прогноза.

TERMINALbash — uvicorn-service

> Ready. Click "Simulate Deployment Flow" to run.

ARTIFACT INSPECTOR Live

Simulate flow to view loaded production artifacts.

Question 1

Which feature of a Jupyter notebook makes it unsuitable for production deployment?

It primarily uses Python code

It is inherently stateful and resource-intensive

It cannot directly access the GPU

Question 2

What is the primary purpose of converting a PyTorch model to TorchScript or ONNX before deployment?

Optimization for faster C++ execution and reduced Python dependency

To prevent model theft or reverse engineering

To automatically handle input data preprocessing

Question 3

When designing a production API, when should the model weights be loaded?

Once, when the service initializes

At the start of every prediction request

When the first request to the service is received

Challenge: Defining the Minimal Service

Plan the structural requirements for a low-latency service.

You need to deploy a complex image classification model ($1\text{GB}$) that requires specialized image preprocessing. It must handle $50$ requests per second.

Step 1

To ensure high throughput and low average latency, what is the single most critical structural change needed for the Python script?

Solution:
Refactor the codebase into isolated modules (Preprocessing, Model Definition, Inference Runner) and ensure the entire process is packaged for containerization.

Step 2

What is the minimum necessary "artifact" to ship, besides the trained weights?

Solution:
The exact code/class definition used for preprocessing and the model architecture definition, serialized and coupled with the weights.